Flexibility has a real cost
It is common for people to ask UI designers to design a system as flexible as possible. Many believe that it is always better for something to be flexible. They think the more flexible the system is, the better the overall experience of the system. However, it is not always true. When we say this design is more flexible than the other one, we are saying that this design can handle more use cases, conditions, or scenarios. In other words, it performs more functions than a less flexible system. But, because it can do more, it often is more complex, which in turn decreases the usability of the system.
A great example from Universal Principles of Design about this tradeoff between flexibility and usability is the comparison between a Swiss Army Knife and corresponding individual tools. Swiss Army Knife has many attached tools that increase its flexibility, but in order to put all those tools in one tool, it sacrifices usability – users spend more time looking for the needed tool and then carefully digging out the tool. The complexity also has impacts on the Swiss Army Knife’s size and shape, which results in a less comfortable handle than corresponding individual tools.
Below diagram shows that the more flexible a UI is, the more it costs.
So why flexible?
Knowing this relationship, it seems that flexibility only decreases usability — what benefit does it bring to the table? In my opinion, perhaps it is only beneficial to build a system flexible when you can’t anticipate future uses of the system. The flexibility helps to accommodate any unexpected future uses so the system does not need to be modified as much as an inflexible system. On the other hand, if you can clearly anticipate the need, flexibility is not needed. Why would add features you know that you are not going to need? There is a cost for keeping unneeded things, e.g. higher maintenance, more complex structure that makes changes difficult, etc. ‘You aren’t gonna need it’ (YAGNI) principle also presents several reasons for not adding features until deemed necessary. To list a few:
- The time spent is taken from adding, testing or improving the necessary functionality.
- The new features must be debugged, documented, and supported.
- Any new feature imposes constraints on what can be done in the future, so an unnecessary feature may preclude needed features from being added in the future.
About building a flexible system vs. a specialized system, a really great example from Universal Principles of Design is a comparison between personal computer and video game console. We use computer to do all sort of things and can’t anticipate the future uses of the computer, thus the flexibility of it. Game console, on the other hand, is built merely for the need to play games. It is a specialized system which does not need the same level of flexibility as PC because we can fully anticipate the uses of it.
How flexible?
Knowing about these key factors, when approaching the problem of how flexible a system should be, we can tackle the problem via the following practices:
1) Clearly define the uses of the system.
Only when we clearly define the uses, can we know whether flexibility is needed. Requirement analysis itself is a topic that will require a whole series of posts, but knowing that this has to be done is critical.
2) Compare levels of flexibility with the costs in mind
As mentioned previously, increased flexibility has a cost in terms of usability and development effort. So we have to look at all factors together. What I often do is put design candidates with different level of flexibility side by side. Play with the different UI just as if I am a user to actually feel the pros and cons of each design.
An example involves a screen for setup of sending system notification emails, e.g. error reports. Should the flexibility to be provided to allow the From Address and Sender Name to be edited?
Things like From Address and Sender Name, once are set up, may never change. Allowing these to be changed like in the first design below introduces more user errors and longer setup time, thus reduces usability. The second design does not allow these to be changed, but could cause some confusions – why these are read-only? Do I need a higher permission level to edit them? The third design allows these to be editable but also provides default/suggested values, which increases the flexibility without reducing much of the usability. By comparing these 3 designs together, a decision can be quickly made.
Aside from usability cost, we also have to deal with the cost of time and money. Consider the same designs above. If the first design costs $1, the second $100, and the third $1,000, the first design is mostly going to be favored. Development cost like this can have a great impact on the decision. What I often do is presenting all the cost factors to stakeholders and work out a decision together.
3) Stop when you have to
During the system design, we will apply the first 2 steps and create designs with high flexibility and low cost. When design phase is over, we will hand it over to development team. Whatever level of flexibility we have in design at that point is the level the system will have. Every project has a time constraint. Even if you don’t want, it is going to decide the level of flexibility for you.
I covered a basic introduction to flexibility and a few practices we apply to our projects. There are numerous discussions on software flexibility out there. Many of them are around flexibility on software architecture, but the basics are still the same – Flexibility has a cost and it is beneficial when we can’t anticipate future uses. I hope that knowing about these basics is helpful!
Stuff 